エクストリームプログラミング読書会 第二回

参加者：@Ueda, @got4416, @kobatomo, @ramusara

進捗：2章〜４章シンプリシティまで(9ページ)

2章　運転を学ぶ

気になった所

チームで開発しているとどのプラクティスがゴールを近づけるか、遠ざけているかわかるようになる。確かに(@kobatomo)

近づけているものは、「ペアプロ」「ユニットテスト」「有識者レビュー」「専念できるように他のプロジェクトとの調整」

遠ざけているものは、「一人で抱えこみ、相談できないこと(人 or 環境)」思い込みによる認識違いの出戻り。マルチタスク(@kobatomo)

顧客は、システムの内容を運転する。チーム全体は、開発プロセスを運転する。開発フェーズ、顧客フェーズそれぞれあることを再認識。(@kobatomo)

小さな軌道修正をかけながら、適応することができる。(@Ueda)

助手席からハンドル触るのは日本の道路交通法的にいかがなものか　気になった(@Ueda)

どんどん追加仕様を受けている間に破綻してしまった。(@Ueda)

バッチ系を競合入札で落としたけど、いつまでたってもできないプロジェクト(@Ueda)

疑問

XPのパラダイム適応するの意味とは？適応するとは、状況を受け入れるということ?(@got4416) 極端にいうとウォータフォールで進める開発側。部分的に使ってみたいお客様。そういう状況に対応する。(@Ueda)

注意して、変更して、適応するでは？(@ramusara)

変更する前に、自分が受け入れ態勢に入る. (@got4416)

変化を受け入れることが適応と考える(@Ueda)

3章　価値、原則、プラクティス

疑問

XPを学ぶこととエクストリームにプログラミングすることには大きな違いがある？何が違うんだろう？(@kobatomo)　こうやって読書会をすることも学ぶの一環では？。(@kobatomo) XPを学ぶということを本を読むだけとしてとらえている(@Ueda)

知ることと実践は、違う.やって見てわかることがある(@got4416)

エクストリーム"な"状態

エクストリームとは？(@ramusara) 効果的(@got4416)

変化を受けいれるということ(@Ueda)(@kobatomo)

プラクティスの話。どうして明確にしておくと何かを始めるきっかけになるのか？(@kobatomo)

プラクティスを明文化してないので、どういったメリットがあるのだろうか？(@kobatomo)

プラクティスは、日本語でいうとなんだろう?(@got4416)

プラクティスを明確にするとは、作業手順書みたいなもの？(@ramusara)(@Ueda)

やり方がしっかりと身についた状態にすること(@Ueda)

自分が持っていないものも入っている(@ramusara)

Howのこと(@ramusara)

"日常的な取り組み"とあるから、もう少し広い意味があるかも？(@ramusara)

@kkd に聞いてみよう。次回。

プラクティスとは実践であり、実際の行動です。行動は価値が元になっています。本書の後で出てきますが、「価値とプラクティスの乖離」ということが起こりえます。それは実は自分が「価値」と信じているつもりが、本心では価値ではなく、行動を伴っていないということです。自分が大事にしているとことを、行動で表すこと、つまり自分に嘘をつかないこと、が大事です(@kkd)

価値は、日常的に大事なものでしょうか？(@got4416)

自分が重要と考えていることが価値。(@Ueda)

そのプロジェクト内では普遍的ということと思う。(@ramusara)

大事。目指すゴールとして捉えている(@kobatomo)

いちごの隣にマリーゴールドをおくとの価値とは？(@got4416)

生産者視点の価値は、売れるイチゴを作ることができる(@kobatomo)

消費者視点の価値は、美味しいイチゴを食べることができる(@kobatomo)

コンパニオンプランティングを理解すること(@Ueda)

Howをしたらゴールにつながるというのではないぞ。原則を理解していることが大事。(@ramusara)

なんのためにそれをするのか？　原則と考える(@ramusara)

価値が変われば、原則が変わる。(@ramusara)

気になった所

運転を学ぶ。で車の運転は、ドライバー以外が寝ててもゴールには行ける。(@ramusara) 自転車でも良いのでは？(@ramusara)

ペアプロを想定してのメタファでは？(@Ueda)

運転のメタファーは「小さな軌道修正」を強調するために使っていると考えられます。なので、ドライバーが寝てるとか、ゴールが正しいとか、言う話はこの例え話のスコープ外ですね。Kentはたとえ話をよく使いますが、基本はAをBですべてたとえようとしているのではなく、AのポイントをBでたとえてわかりやすく伝えようとしている、と理解しよう。(@kkd)

ゴールが正しいかどうかが述べていない。(@ramusara)

仮説検証も大事だよね。(@ramusara)

10km先を目指すか、1km先のポスト目指すか。1km先で状況把握する。(ramusara)

造園家。ポールは造園の善し悪しを判断する高度な感覚を持っている(@got4416)

3章は、次章に続く言葉の定義の章と認識(@Ueda)

XPの価値と少なくとも複数のプラクティスを共有したコミュニティに参加して自分の知っていることを誰かに伝えるしかない。(@Ueda) これが、この本を押した理由です。(@ueda)

プログラマーは、コミュニケーションよりも自己防衛に価値を置いている。この状況では、危機的状況だ(@ramusara)

4章　価値

気になった所

ソフトウェア開発に関わる人であれば、何が重要であるかの感覚を持っている。(@ramusara)

SIer経験者は、すごく細かいところまで考えている。安全に倒した設計が、されている。

反対(Web系エンジニア)は、「壊れたら直せばいいじゃない」

同じものを作っても、人によって価値観が違うと感じる。(@ramusara)

チームとしてどのように振る舞うべきかである。その通り。(@ramusara)

そもそもチームで何を価値とするかを共有・違いを認識していないのが問題。(@kkd)

その現場で何が一番大事なのか、それによってやることが変わってくる。SIとひとくくりにいってもいろいろある。その現場現場で何を一番重要視するかをまず話そう。例えば、インセプションデッキのトレードオフスライダーを顧客と一緒にやるのはいいですね。(@kkd)

4章 - コミュニケーション

気になった所

どんどん成果が上がらないが時間が過ぎていく。悪循環を思い出す。(@Ueda)

経験していくとコミュニケーションが必要とわかるが、経験が浅いとコミュニケーションがうまく取れなくて仕事がうまく進めなくなる(@Ueda)

報連相。(@got4416)

コミュニケーションを取りすぎる人がいる。(@Ueda)

説明に一所懸命になっている人。その人は、何に価値を置いているのかなー(@ramusara)

自己防衛のため。(@Ueda)

本質だけ話すればいいのに、、(@ramusara)

「コミュニケーションとは何のためなのか？」を考えるといいですね。やり方は色々あるし(@kkd)

問題が起きたとき、コミュニケーションの欠如によるものかどうか自問する。この考え方が新しいと思った。(@kobatomo)

4章 - シンプリシティ

疑問

気になった所

よくわかる。(テストのしやすさ、コードを短くシンプルに可読性の向上、シンプルなクラス設計)(@kobatomo)

アジャイルサムライであった。今回のスプリントでやるべきこと。後で考えること。今はやらないこと。と理解。後で考えることを入れたら、

確かに、最優先事項でやるべきこと以外のコミュニケーションも増えるし、リリースも遅れる。のは理解できる。(@kobatomo)

ファイルを分割することが分かっていなくて、main.cに全てを書いたー。30年前。(@Ueda) バランスよく分割することが見えてきた(@Ueda)

リファクタリングもする。一つ一つの作業を単純化している(@Ueda)

過度にしすぎるとだめ。バランスが難しい。(@got4416)

Simplicityだけコミュニケーションと関わらない。(@ramusara)

XPで早くFeedBackを得たい => だから Simplicyは、(重要な)5つのうちに入っている?(@ramusara)

ふりかえり

Keep, 感想

事前に呼んでくるのは、今後も継続(@kobatomo)

音声の品質が改善された。 >> iPhoneのイヤホンにマイクが付いていることに気づいたので今回はそれを導入(@kobatomo)

昔の辛かった時期を思い出した.その経験は、今の仕事に活かせているぜー(@Ueda)

意味が伝わらないところがあるなー。人に教えるのは難しい。(@got4416)

すごい短い言葉。人によって解釈が違うことが面白い.uedaさんの昔話もgoodです(@ramusara)

次回

11/15 19:30-21:004章フィードバック〜5章最後まで。